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SUPPLEMENTAL APPEAL BRIEF 

Sir: 

This is a Supplemental Appeal Brief submitted in response to the Notice of Non- 
Compliance mailed on June 19, 2006, supporting an appeal by the Applicants from the Final 
Office Action dated August 24, 2005 of claims 22-41 of the above-identified application. The 
appealed claims appear in Appendix A. Also enclosed are Appendix B, an Evidence Appendix 
and Appendix C, a Related Proceedings Appendix. 

REAL PARTY IN INTEREST 

The real party in interest is the assignee, Mitel Networks Corporation, 350 Leggett Drive, 
Ottawa, Ontario, Canada, the owner by assignment, as recorded on July 14, 2005 at reel/frame 
016345/0283. 

RELATED APPEALS AND INTERFERENCES 
There are no related appeals or interferences which will directly affect or be directly 
affected by or have a bearing on the Board's decision in this appeal. 

STATUS OF CLAIMS 
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Original claims 1-21 were cancelled. Claims 22-41 replaced claims 1-21, and claims 22- 
41 are all pending, rejected, and the subject of this appeal. 



STATUS OF AMENDMENTS 
No amendments were made subsequent to the Final Rejection. Pending claims 22-41 
appear in Appendix A. 

SUMMARY OF CLAIMED SUBJECT MATTER 
The applicants' invention relates to a method for controlling telephone connections for 
internet protocol communications by providing a message protocol. Messages are used to 
facilitate communication between an IP phone and an Ethernet PBX, with the invention 
providing a message template that "wraps" the messages communicated between the IP phone 
and the PBX. (p. 3, 1. 6-8) The message template is added to each message generated, comprising 
a Protocol Header that includes a Protocol Type indicator, a Device Number indicator, and a 
message type indicator, (p. 1, 1. 28-30) 

Specifically, claim 22, the only independent claim on appeal, is directed to "a method of 
communication between an IP phone and a network-implemented PBX", (claim 22), (see p. 1,1. 
20-23). The method utilizes the specific steps of "generating a message to be exchanged between 
the IP phone and the PBX" (see p. 5, 1. 10-11, 1. 17-p. 6, 1. 25), "encapsulating the message with 
a Protocol Header and an IP Message body (see p. 3, 1. 10-13), wherein the Protocol Header 
includes an indication of Protocol Type for denoting whether the message is an IP message or an 
encapsulated non- IP message (see p. 2, 1. 3-5), a Device Number for denoting by means of MAC 
(Media Access Control) an address within the PBX to which the message is to be transmitted or 
from which the message is to be received (see pg. 2, 1. 1-2, p. 4, 1. 11-17), and Message Type for 
identifying the type of message contained in the IP Message Body (see pg. 2, 1. 2-3, p. 4, 1. 21- 
42); and, transmitting the encapsulated message (see pg. 5, 1. 10-11, 17-18). 

The invention encapsulates messages exchanged between an IP phone and a network- 
implemented PBX with a Protocol Header and an IP Message Body, however, claim 22 is more 
specific, requiring within the Protocol Header, an indication of Protocol Type for denoting 
whether the message is an IP message or an encapsulated non-IP message, as well as having the 
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Device number and Message Type indicator (see p. 3, 1. 10-13, see also p. 5, 1. 22-24, p. 6, 1. 31- 
33, 1. 44-46, p. 7, 1. 16-18). This aspect of the invention is important for identifying which of 
multiple messaging protocols is contained within the encapsulated message (i.e. an IP message 
or a non-IP (e.g. legacy-PBX) message). By defining the Protocol Type within the Protocol 
Header, call control functionality from legacy-PBX systems may be extended to an Ethernet or 
LAN-implemented PBX. 

An example of a message encapsulated with the Protocol Header is illustrated on page 3, 
1. 10-47. The Protocol Type is illustrated by way of example as either a Minet IP message or a 
MINET MTS22 message, (p. 4. 1. 1-10) The various messages exchanged are illustrated for 
example, in the Registration Sequence of Figure 1, and the description on page 5, line 9-page 6, 
line 39. 

GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
1. CLAIMS 22-41 STAND REJECTED AS BEING OBVIOUS UNDER 35 U.S.C. § 
103(a) OVER MATSUMOTO ET AL., U.S. PUBLICATION NO. 2005/0026545 Al, ("THE 
'545 PUBLICATION") IN VIEW OF THORTON ET AL., U.S. PATENT NO. 6,363,065 
("THE '065 PATENT"). 

ARGUMENT 

CLAIMS 22-41 ARE NOT OBVIOUS OVER THE CITED REFERENCES 
I. LEGAL STANDARD 

To establish a prima facie case of obviousness based on a combination of references, 
there must be some teaching, suggestion or motivation in the prior art to make the specific 
combination that was made by the applicant. In re Raynes . 7 F.3d 1037, 1039, 28 U.S.P.Q.2D 
(BNA) 1630, 1631 (Fed. Cir. 1993); In re Oetiker , 977 F.2d 1443, 1445, 24 U.S.P.Q.2D (BNA) 
1443, 1445 (Fed. Cir. 1992). Obviousness can not be established by hindsight combination to 
produce the claimed invention. In re Gorman, 933 F.2d 982, 986, 18 U.S.P.Q.2D (BNA) 1885, 
1888 (Fed. Cir. 1991). As discussed in Interconnect Planning Corp. v. Feil 774 F.2d 1 132, 1143, 
227 U.S.P.Q. (BNA) 543, 551 (Fed. Cir. 1985), it is the prior art itself, and not the applicant's 
achievement, that must establish the obviousness of the combination. 
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The Patent and Trademark Office has the burden under section 103 to establish a prima 
fascia case of obviousness. In re Piasecki 223 USPQ 2d 785 (Fed. Cir. 1984). They can satisfy 
this burden only by showing some objective teaching in the prior art or that knowledge generally 
available to an ordinary skill in the art would lead the individual to combine relevant teachings 
of the references. In re Fine , 837 F.2d 1071 (Fed. Cir. 1988). 

II. CLAIM 22 IS NOT OBVIOUS 

The applicants' invention is a method for controlling telephone connections for internet 
protocol communications by providing a message protocol. These messages facilitate 
communication between an IP phone and an Ethernet PBX. The invention provides a message 
template that "wraps" the messages communicated between the IP phone and the PBX. (p. 3, 1. 
6-8) The message template is added to each message generated, comprising a Protocol Header 
that includes a Protocol Type indicator, a Device Number indicator, and a message type 
indicator. 

Matsumoto describes a method of registering an IP terminal device to a PBX wherein the 
IP terminal device is registered as a radio telephony device in a database of the PBX. By 
registering the IP terminal device as a radio telephony device in the database, the device can 
receive a variety of supplemental services provided by the PBX. Moreover, registration of the IP 
terminal device as a radio telephony device allows for moving the IP terminal device from one 
location to another without updating the PBX. 

The Examiner has admitted that Matsumoto does not teach encapsulation of the message 
as recited in claim 22, and relies on Thorton for the encapsulation. 

Thorton discloses a telephone gateway which, when operated with a similar peer 
Gateway and each being connected at opposite ends of the Public Switched Telephone Network 
(PSTN) and IP data network, dynamically switches a call alternately between the data network 
and the PSTN based on real-time measurements of quality of service associated with the data 
network. However, while Thorton teaches forming data into IP packets, there is no teaching or 
suggestion of the use of a Protocol type indicator within a protocol header for encapsulating a 
message. 

One citation by the examiner only indicate that packets received by a microcontroller for 
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any one channel, assembles the packets for that channel into proper IP packets with necessary IP 

headers, including originating and destination IP addresses. These are transmitted via internal 

Ethernet interface and Ethernet network transceiver 255, to the LAN for subsequent routing to a 

peer gateway. (Col. 14, 1. 35-45 ). 

The Examiner referred then cites to Thorton, at col. 23, but this only refers to embedded 

message type information: 

"A message consists of a system message header and a variable length data 
field. The header specifies message type, a unique system identification (USID) 
associated with the calling process. Each process and driver has an associated two- 
byte USID. A USID is associated with each different function, not with a given 
hardware device, such as a specific circuit." (Col. 23, 1. 15-21, Emphasis added) 

Nowhere in Thorton can one skilled in the art find any teaching or suggestion for use of a 
Protocol Header as defined relative to claim 22. Claim 22 requires a Protocol Header that has an 
indication of Protocol Type for denoting whether the message is an IP message or an 
encapsulated non-IP message, the Protocol Header encapsulating the message. This is important 
for identifying which of multiple messaging protocols is contained within the encapsulated 
message (i.e. an IP message or a non-IP (e.g. legacy-PBX) message). By defining the Protocol 
Type within the Protocol Header, call control functionality from legacy-PBX systems may be 
extended to an Ethernet or LAN -implemented PBX. Absent the teaching or suggestion for 
encapsulating a message with such a Protocol Header, claims 22-41 are not obvious in view of 
the proposed combination of references. 

III. THE REJECTION IS BASED ON SPECULATION 

The Examiner rejected the above argument in the Advisory Action, not by reference to 

any suggestion found in the cited prior art, but by engaging in pure speculation, The examiner 

opines that it is well known that "there is a Protocol field, which specifies the type of the 

encapsulated protocol, in the IP packet header", yet cites no evidence in the prior art supporting 

this contention. In fact, the cited art specifically has no such disclosure, nor would it be inherent 

since such Protocol types are not even mentioned. 

"A rejection based on section 103 clearly must rest on a factual basis, and 
these facts must be interpreted without hindsight reconstruction of the invention from 
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the prior art. In making this evaluation, all facts must be considered. The Patent Office 
has the initial duty of supplying the factual basis for its rejection. It may not, because 
it may doubt that the invention is patentable, resort to speculation, unfounded 
assumptions or hindsight reconstruction to supply deficiencies in its factual basis." In 
re Warner, 54 C.C.P.A. 1628, 379 F.2d 1011, 1017, 154USPQ 173, 178 (CCPA 
1967), cert, denied, 389 U.S. 1057, 19 L. Ed. 2d 857, 88 S. Ct. 811 (1968). 

Here, the Examiner did not provide evidence, other than speculation, that the above 
claims would have been obvious to one of ordinary skill. See In re Jones, 958 F.2d 347, 351, 21 
USPQ2d 1941, 1944 (Fed. Cir. 1992), In re Laskowski, 871 F.2d 115, 117, 10 USPQ2d 1397, 
1398-99 (Fed. Cir. 1989); In re de Jong, 57 C.C.P.A. 701, 416 F.2d 1401, 1404, 163 USPQ 479, 
482 (CCPA 1969). 

There is no evidence of record supporting the examiners' proposed combination, and 
even if made it does not arrive at the applicants' invention. Clearly, there is no teaching of the 
encapsulation of a message with a Protocol Header including Protocol Type, Device Indicator 
and Message Type indicator together. Consequently, claims 22-41 are not obvious and this 
rejection should be overruled. 



VI. CONCLUSION 

Based on the above, claims 22-41 are unobvious and reversal of the rejection is 
respectfully requested. 



Dated: June 21, 2006 Respectfully submitted, 



/WJS/ 
William J. Sapone 
Reg. No. 32,518 

Attorney for Applicant 

Coleman Sudol Sapone P.C. 

714 Colorado Avenue 

Bridgeport CT 06605 

203-366-3560 

email : wj spatent@aol. com 
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APPENDIX A 



22. A method of communication between an IP phone and a network-implemented PBX 
comprising: 

generating a message to be exchanged between said IP phone and said PBX; 
encapsulating said message with a Protocol Header and an IP Message body, wherein 
the Protocol Header includes an indication of Protocol Type for denoting whether the 
message is an IP message or an encapsulated non- IP message, a Device Number for denoting by 
means of MAC (Media Access Control) an address within said PBX to which said message is to 
be transmitted or from which said message is to be received, and Message Type for identifying 
the 

type of message contained in the IP Message Body; and, 
transmitting the encapsulated message. 

23. The method of claim 22, wherein said message is a Device Registration request, and 
further comprising transmitting the Device Registration request from said IP Phone to said PBX 
responsive to one of either a power-up or a resetting of said IP phone. 

24. The method of claim 23, further comprising generating, encapsulating and 
transmitting a Device Registration request Acknowledgment message from said PBX to said IP 
phone. 

25. The method of claim 24, further comprising generating, encapsulating and 
transmitting a Device De-Registration Request message from said IP phone to said PBX. 

26. The method of claim 25, further comprising generating, encapsulating and 
transmitting a Device De-Registration Acknowledgment message from said PBX to said IP 
phone. 
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27. The method of claim 22, wherein said message is a Device ICMP Echo (ping) 
request, and further comprising transmitting the Device ICMP Echo (ping) request from said 
PBX to said to said IP Phone for testing for the presence of said IP phone. 

28. The method of claim 27, further comprising generating, encapsulating and 
transmitting a device ICMP Echo (Ping) results message from said IP phone to the PBX. 

29. The method of claim 24, further comprising generating, encapsulating and 
transmitting a device tone generation request message from said PBX to said IP phone 
responsive to registration of said IP phone with said PBX and said IP phone going off-hook. 

30. The method of claim 29, further comprising generating, encapsulating and 
transmitting a Remove Tone device tone generation request message from said PBX to said IP 
phone. 

31. The method of claim 30, further comprising generating, encapsulating and 
transmitting an Open Receive Stream Request from said PBX to said IP phone for establishing 
an audio path from said PBX to said IP phone. 

32. The method of claim 31, further comprising generating, encapsulating and 
transmitting an Open Receive Stream Acknowledgement from said IP Phone to said PBX. 

33. The method of claim 32, further comprising generating, encapsulating and 
transmitting a Close Receive Stream Request from the PBX to the IP Phone. 

34. The method of claim 33, further comprising generating, encapsulating and 
transmitting a Close Receive Stream Acknowledgement from the IP Phone to the PBX. 

35. The method of claim 33, further comprising generating, encapsulating and 

8 



transmitting an Open Transmit Stream Request from said PBX to said IP phone for establishing 
an audio path from said IP phone to said PBX. 

36. The method of claim 35, further comprising generating, encapsulating and 
transmitting an Open Transmit Stream Acknowledgement from the IP Phone to said PBX. 

37. The method of claim 36, further comprising generating, encapsulating and 
transmitting a Close Transmit Stream Request from the PBX to the IP phone. 

38. The method of claim 37, further comprising generating, encapsulating and 
transmitting a Close Transmit Stream Acknowledgement from the IP phone to the PBX 

39. The method of claim 22, wherein said message is a Device IP address update request 
message, and further comprising transmitting the Device IP address request from said PBX to 
said IP phone for initiating update of any change in IP address of said IP phone. 

40. The method of claim 39, further comprising generating, encapsulating and 
transmitting a Device IP address update acknowledgement from the IP phone to said PBX. 

41. The method of claim 22, wherein said message is a legacy call control message. 
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APPENDIX B 



EVIDENCE APPENDIX 



NONE 
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APPENDIX C 
RELATED PROCEEDINGS APPENDIX 



NONE 
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